The present invention relates to providing security for programming objects, and more particularly relates to an object security service for providing caller identities.
In many information processing applications, a server application running on a host or server computer in a distributed network provides processing services or functions for client applications running on terminal or workstation computers of the network which are operated by a multitude of users. Common examples of such server applications include software for processing class registrations at a university, travel reservations, money transfers and other services at a bank, and sales at a retail business. In these examples, the processing services provided by the server application may update databases of class schedules, hotel reservations, account balances, order shipments, payments, or inventory for actions initiated by the individual users at their respective stations.
In a server application that is used by a large number of people, it is often useful to discriminate between what different users and groups of users are able to do with the server application. For example, in an on-line bookstore server application that provides processing services for entering book orders, order cancellations, and book returns, it may serve a useful business purpose to allow any user (e.g., sales clerk or customers) to access book order entry processing services, but only some users to access order cancellation processing services (e.g., a bookstore manager) or book return processing services (e.g., returns department staff).
Network operating systems on which server applications are typically run provide sophisticated security features, such as for controlling which users can logon to use a computer system, or have permission to access particular resources of the computer system (e.g., files, system services, devices, etc.) In the Microsoft Windows NT operating system, for example, each user is assigned a user id, which has an associated password. A system administrator also can assign sets of users to user groups, and designate which users and user groups are permitted access to system objects that represent computer resources, such as files, folders, and devices. During a logon procedure, the user is required to enter the user id along with its associated password to gain access to the computer system. When the user launches a program, the Windows NT operating system associates the user id with the process in which the program is run (along with the process"" threads). When a thread executing on the user""s behalf then accesses a system resource, the Windows NT operating system performs an authorization check to verify that the user id associated with the thread has permission to access the resource. (See, Custer, Inside Windows NT 22, 55-57, 74-81 and 321-326 (Microsoft Press 1993).)
A thread is the basic entity to which the operating system allocates processing time on the computer""s central processing unit. A thread can execute any part of an application""s code, including a part currently being executed by another thread. All threads of a process share the virtual address space, global variables, and operating-system resources of the process. (See, e.g., Tucker Jr., Allen B. (editor), The Computer Science and Engineering Handbook 1662-1665 (CRC Press 1997).)
In object-oriented programming, programs are written as a collection of object classes which each model real world or abstract items by combining data to represent the item""s properties with methods (e.g., program functions or procedures) to represent the item""s functionality. More specifically, an object is an instance of a programmer-defined type referred to as a class, which exhibits the characteristics of data encapsulation, polymorphism and inheritance.
Data encapsulation refers to the combining of data (also referred to as properties of an object) with methods that operate on the data (also referred to as member functions of an object) into a unitary software component (i.e., the object), such that the object hides its internal composition, structure and operation and exposes its functionality to client programs that utilize the object only through one or more interfaces. An interface of the object is a group of semantically related methods of the object. In other words, the client programs do not access the object""s data directly, but must instead call methods on the object""s interfaces to operate on the data.
Polymorphism refers to the ability to view (i.e., interact with) two similar objects through a common interface, thereby eliminating the need to differentiate between two objects. Inheritance refers to the derivation of different classes of objects from a base class, where the derived classes inherit the properties and characteristics of the base class.
In object-oriented programming, it is common for a first object to call other objects to perform work on its behalf. These other objects are sometimes referred to as being xe2x80x9cdownstreamxe2x80x9d from the first object because the method calls figuratively flow from an upstream object (i.e., the first or caller object) to downstream objects (i.e., the other called objects). The downstream objects may reside at remote locations or run in other processes; therefore, the downstream objects may be associated with identities different from the first object. For example, a typical arrangement is to associate objects executing in certain processes with the system user. Requests for the user identity of calls from these objects will provide the identity xe2x80x9csystem.xe2x80x9d
A problem arises when an object executed by a user calls one of the system objects to perform work for it because a call from the system object apparently originates from the system user. Therefore, the security services cannot determine which user actually initiated the original call (e.g., whether it was a manager or a customer).
For example, an application for tracking employee time at a bookstore might create a timekeeping component at startup and associate the timekeeping component with the user xe2x80x9csystem.xe2x80x9d The timekeeping component tracks employees"" hours by calling other components to write information to a log and other components to edit the log.
Subsequently, when users access the timekeeping component, it is desirable for the identity of the accessing user to be associated with the component, not the system identity. Otherwise, security checks for the writing and editing components cannot differentiate between users to determine if the user is permitted to edit the log (e.g., whether the user is a manager). Also, for auditing purposes, it is desirable to track which user performed what actions. Under the described scenarios, information about the direct caller (i.e., the xe2x80x9csystemxe2x80x9d) is not useful. Therefore, a mechanism is needed by which a component can supply an identity other than that associated with its process when making calls to other components.
One attempted solution to this downstream object identity problem is provided by Windows NT, which supports a feature called xe2x80x9cimpersonation.xe2x80x9d Using impersonation, a programming component can specify the identity of another, and calls from the component appear to be originating from that user. Additionally, components can specify an impersonation level, indicating whether or not they allow themselves to be impersonated.
However, impersonation under Windows NT requires logic in the component call various security application programming interfaces (or APIs), requiring application developers to become familiar with the APIs and the inner workings of the operating system""s security framework. Further, the complexities of the APIs may lead to programming errors when implementing impersonation, resulting in holes in the application""s security scheme or other undesired operation. Finally, each developer may use the APIs to develop a different impersonation scheme, making it considerably difficult to combine applications from different developers.
Another attempted solution of the downstream identity problem is provided by an application execution environment called Microsoft Transaction Server, a product separate from Windows NT which provides runtime services to application components.
At runtime, Microsoft Transaction Server monitors execution of the application to provide the identity of an application component""s creator and direct caller. Under certain scenarios, however, Microsoft Transaction Server fails to provide relevant information for security checks.
For example, if a first component associated with a user identity (e.g., a manager) invokes a second component created by the system that invokes a third component created by the system, Microsoft Transaction Server will provide the creator (i.e., the system) and the direct caller (i.e., the system) identities of the third component. Thus, Microsoft Transaction Server still fails to provide information helpful in providing accurate identity information for the third component.
The present invention includes a security framework for objects in which a caller chain is built with logic outside the objects. Since the caller chain is built transparently to the objects, the application developer avoids having to incorporate security logic into application objects. The caller chain is available to security services, which can perform access checks based on information in the chain. The caller chain is further available to the objects for implementing a custom security scheme.
In one aspect of the invention, impersonation can be specified declaratively (i.e., outside the logic of the object) for an object, an interface, or a method. At run time, the security framework automatically invokes impersonation, and an object impersonates its callers. Thus, an object developer can specify that certain objects use the impersonation feature and avoid having to understand the inner workings of the security framework.
In another aspect of the invention, a minimum authentication level is tracked for the caller chain. The minimum authentication level is used to control access to objects, interfaces, and methods.
In still another aspect of the invention, a user can specify a group of objects trusted to provide other objects"" identities when the caller chain traverses a method invocation queue.
In yet another aspect of the invention, the caller chain is used in conjunction with roles. Roles are defined at development time and specify logical groups of users independent of actual users. When the application is deployed on a host computer system, the roles are populated with actual users recognized by the host computer system. Access to an object""s functionality can be limited to specified roles declaratively through a graphical user interface or programmatically, by including a system call in the object to test for role membership.
Additional features and advantages of the invention will be made apparent from the following detailed description of illustrated embodiments, which proceeds with reference to the accompanying drawings.